1. Field of the Invention
The present application relates to encrypted WLAN (Wireless Local Area Network) communication methods and corresponding devices, integrated circuit chips, computer program products and computer systems, and in particular to the hardware/software implementations thereof.
2. Description of the Related Art
A wireless local area network is a flexible data communication system implemented as an extension to or as an alternative for a wired LAN. Using radio frequency or infrared technology, WLAN systems transmit and receive data over the air, minimizing the need for wired connections. Thus, WLAN systems combine data connectivity with user mobility.
Today, most WLAN systems use spread spectrum technology, a wide band radio frequency technique developed for use in reliable and secure communication systems. The spread spectrum technology is designed to trade off bandwidth efficiency for reliability, integrity and security. Two types of spread spectrum radio systems are frequently used: frequency hopping and direct sequence systems.
The standard defining and governing wireless local area networks that operate in the 2.4 GHz spectrum is the IEEE 802.11 standard. To allow higher data rate transmissions, the standard was extended to 802.11b, which allows data rates of 5.5 and 11 Mbps in the 2.4 GHz spectrum. Further extensions exist.
In order to address existing security gaps of the 802.11 standard's native security, i.e. the WEP (Wired Equivalent Privacy) protocol, the 802.11i security standard was developed. This enhanced security standard relies on the 802.1x standard for port-based access control, and the TKIP (Temporal Key Integrity Protocol) and CCMP (Counter-mode Cipher block chaining Message authentication code Protocol) protocols for data frame encapsulation and decapsulation. 802.1x provides a framework for WLAN station authentication and cryptographic key distribution, both features originally missing from the 802.11 standard. The TKIP and CCMP protocols are cipher protocols providing enhanced communication security over the original WEP protocol, the TKIP protocol being targeted at legacy equipment, and the CCMP protocol being targeted at future WLAN equipment.
According to both cipher protocols, there is generated an individual character string for each data frame used for encrypting the data frame. This encryption character string is based on a packet number or sequence number inserted in the data frame indicating data frame ordering. Out of order data frames are discarded. Further, the encryption character string depends on the MAC (Medium Access Control) addresses of the communicating WLAN counterparts, e.g., a WLAN station and a WLAN access point. At the transmitting WLAN counterpart, an integrity value is calculated from the original plaintext frame data and is inserted into the data frame during encapsulation in order to allow the receiving WLAN counterpart to verify whether the decapsulated frame data are identical to the original plaintext frame data. According to the TKIP and CCMP protocols, this integrity value is not only a simple CRC (Cyclic Redundancy Check) checksum, but is generated using a cryptographic MIC (Message Integrity Code) calculation.
Referring now to FIG. 1A, which illustrates an encapsulation process according to the TKIP protocol, there is generated a data frame specific key 118 from a temporal key 102, the transmitter address 104, and the sequence number 106. The data frame specific key 118 is split into a data frame specific initialization vector (IV) 122 and a general, data frame independent RC4 (Rivest's Cipher 4) key 120. Both the IV 122 and the RC4 key 120 are fed into the RC4 encapsulation process 132 to encapsulate an input plaintext data frame 130. The input plaintext data frame 130 may be generated by fragmentation 128 of a precedent unfragmented plaintext data frame 126. The plaintext data frame 126 contains an integrity value calculated by MIC calculation 124 from the source address 110, destination address 112, and original plaintext data frame 114 using a MIC key 108 and the sequence number 106.
FIG. 1B depicts the RC4 encapsulation process 132, which is performed according to the WEP protocol of the original 802.11 standard. The initialization vector 122 and RC4 key 120 are concatenated in 136 and then input to the RC4 pseudo random key generation 138. The plaintext data frame 130 is used to calculate a CRC checksum in 140 and is then concatenated with the CRC checksum in 142. The encrypted data 146 are generated by bitwise XOR-(exclusive or) gating 144 the concatenated plaintext data frame and CRC checksum resulting from the concatenation 142 with the RC4 pseudo random key generated in 138. The result of the RC4 encryption process 132 is an encrypted data frame 134 containing the initialization vector 122 and the encrypted data 146.
Turning now to FIG. 2A, which illustrates an encapsulation process according to the CCMP protocol, there is constructed Additional Authentication Data (AAD) 212 in 210 using the MAC addresses contained in the frame header 208 of the plaintext data frame 202. An initialization vector 216 is constructed in 214 from the Packet Number (PN) 218 contained in the plaintext data frame 202 and data from the frame header 208. The frame header 208, the additional authentication data 212, the initialization vector 216, the packet number 218, and the plaintext data 220 contained in the plaintext data frame 202 are fed into the CCMP encryption process 224 together with an AES (Advanced Encryption Standard) key 204. The encrypted data frame 226 resulting from the CCMP encryption 224 is concatenated in 230 with a CCMP header, constructed in 222 from the packet number 218 and an AES key ID 206 in order to generate the final encrypted data frame 232.
The CCMP encryption 224 is depicted in FIG. 2B. The data encryption 252 and MIC calculation 254 are performed in parallel. Both the data encryption 252 and the MIC calculation 254 comprise AES encryption 234. To each AES encryption 234 the AES key 204 is input. For clarity reasons, the AES key 204 is not depicted in FIG. 2B. During the data encryption 252, the plaintext data 220 contained in the input plaintext data frame 202 are encrypted blockwise by bitwise XOR-gating 236 data blocks 256 of 128 bits size with the result of AES encrypting 234 a counter preload (PL) 240, 242, 244, 246. Each counter preload depends on the additional authentication data 212, not depicted for clarity reasons, and a consecutive counter value.
The MIC calculation 254 is seeded with the initialization vector 216. The initialization vector 216 is fed into an AES encryption 234 and its output is bitwise XOR-gated 236 with select elements from the frame header 208 and is then again fed into an AES encryption 234. This process continues over the remainder of the frame header 208 and down the length of the plaintext data 220 to compute a final CBC-MAC (Cipher-Block Chaining Message Authentication Code) value of, e.g., 128 bits size. The upper part, e.g., 64 bits of the CBC-MAC are extracted and used in the final MIC. The resulting encrypted data frame 226 includes the plaintext frame header 208 and packet number 218, the encrypted data 258 and the encrypted MIC 250.
FIG. 2C illustrates a regular encryption round of the AES encryption process 234, which is a sequence of four encryption steps. A block 252 of input plaintext data is written into a matrix comprising four lines and a variable number of rows depending on the block size. Each matrix element ai,j corresponds to one byte of the input plaintext data block 252, wherein i=0, . . . 3 denotes the line and j=0 . . . n denotes the row. In the example depicted in FIG. 2C, n=3. In the first encryption step, byte substitution 254, each byte ai,j is substituted with another byte si,j according to substitution rules implemented in a cryptographic substitution box. In the shift row step 256, the elements in each matrix line are cyclically permutated. The mix column step 258 comprises row-wise multiplying the matrix elements with a constant and then XOR-gating the matrix elements with each other. Finally, in the key addition step 260, the results of the mix column step 258 are XOR-gated with an AES round key 264, which has been calculated from the AES key 204. The regular round of the AES encryption 234 is repeated several times by re-entering the encrypted data 262 to the byte substitution step 254. In addition to the regular rounds, the AES encryption 234 comprises an initial key expansion round for generating the AES round key 264 from the AES key 204, and a final round with the mix column step 258 omitted.
To implement the above described communication security techniques or similar approaches known in the art, existing encrypted WLAN communication methods are performed by both executing software-implemented instructions and operating hardware devices that are capable of executing specific functions they are designed for. This may lead to a number of disadvantages.
Referring now to FIG. 3, the steps of communication security are performed by executing software-implemented instructions of a connection set-up function 330 and of an encapsulation/decapsulation function 340 of driver software 310 running, e.g., on a host CPU, and operating a connection set-up circuit 350 and an encapsulation/decapsulation circuit 360 on a WLAN chip 320. Thus, prior art WLAN chips usually suffer from high hardware complexity and costs.
Further, conventional WLAN communication systems often have the disadvantage of producing multiple inter-component data transfer. The steps of executing software-implemented instructions and operating the WLAN chip components 350 and 360 are performed alternately. Thus, the prior art techniques often lead to an intense data traffic between the driver software 310 and the WLAN chip 320, which requires large traffic capacities and bandwidth, and which may also be a severe reason for data faults.
In addition, there is often a security problem in the prior art systems since the data traffic comprises the exchange of intermediate data 390 intended for or resulting from intermediate substeps of the connection set-up or of the data frame encapsulation or decapsulation. The intermediate data 390 may include, e.g., the data frame specific key 118, the additional authentication data 212 or the initialization vector 216. Since the intermediate data 390 may include information on security secrets, e.g., on applied cryptographic keys, their exchange may produce a considerable security gap.
Moreover, conventional systems may suffer from latencies which may occur in the interface connecting the driver software 310 running on the host CPU with the WLAN chip 320. Such latencies usually result in unnecessary deceleration of the communication security and may therefore lead to further problems in achieving efficient transmission data rates.